Subject: Allowing Users to Prefer HPR Routes

From: Mark Cossack <[email-masked]>
Date: Mon, 31 Oct 1994 08:49:37 -0600 (CST)

> I too have a couple of problems with the suggested HPR route
> strategy.

> I agree with Mark that this could direct traffic over routes
> that are non-optimal. Just because a 64K SDLC line is using HPR
> doesn't mean that it is suddenly faster than a 16M T/R that is
> not using HPR !

Here, here, or a 1.5M Frame Relay over a 16M T/R, etc.

> Also - assuming the proposed change went ahead - it appears to be
> a bit of an all-or-nothing approach. What happens in the case of
> a segmented network (ie one partially converted to HPR protocols) ?
> If there is a route that is mostly HPR, but has one or more non-HPR
> segments in the middle, shouldn't the "HPR preferred" indicator
> allow this route to be chosen if there is no HPR-only route ?
> With the current manner in which an HPR route is calculated, the
> non-HPR TGs are given infinite weighting, so this route would be
> avoided. The subsequent route calculation failure would then result
> in no preferrence for HPR TGs even though this is what is indicated
> in the MODE.

> Have I missed something, or do you agree that this is a concern ?

> Dave

I think you raise another good point in your all-or-nothing analysis.
If there is a 'mostly' HPR path and a non-HPR path, the current proposal
falls back to requiring that the 'mostly' HPR path be truly more optimal
to be chosen since it does not pass the 'all' HPR test.  Since you have
fallen back to the optimality test (not HPR vs non-HPR), the proposed
solution of preferring HPR paths has done this customer no good.  He has
to instead rely on having his HPR paths be more optimal than his non-HPR
paths which is how he should be designed it from the beginning.  A
customer that has an HPR backbone with both ISR and ANR coming into it
shouldn't need the 'prefer' method either since its all HPR in the
backbone.

I would also not want to see session setup time lengthened by having two
route calculations.

Mark

---

From: "jim (j.) cobban" <[email-masked]>
Date: Mon, 31 Oct 1994 09:34:00 -0500

In message "Allowing Users to Prefer HPR Routes", 
[email-masked]' writes:

>The solution entails adding a new parameter to the NOF DEFINE_MODE
>command, called HPR_PREFERRED.  The HPR_PREFERRED parameter indicates
>whether HPR routes are preferred when using that mode to establish LU-LU
>sessions.  It allows network managers to associate with a mode name a
>preference to use HPR routes.  It has the added benefit of allowing HPR
>routes to be preferred for any Class of Service associated with that mode
>name.

I am uncomfortable with associating this attribute with the MODE.  I feel
that it violates the traditional interpretation of the difference between
MODEs and COSes.  The MODE was originally created in SNA to describe the
characteristics of the end-to-end session.  COS was introduced in SNA 4.2
(ACF v1.3) when the possibility of alternate routing arose.  As the
architecture of record (page 3-13 under DEFINE_CLASS_OF_SERVICE) states "COS
definitions are used to define the desired characteristics of session
routes."  As a result of the evolution of SNA, and the need to support
back-level application program interfaces which do not provide the ability
to specify a COS explicitly, the DEFINE_MODE includes 
the name of a COS.  However this is the only piece of route related
information present in the MODE definition.  All other attributes of a MODE
definition apply only to the end-to-end characteristics of the
communications.  Since a preference for HPR routes is clearly one of "the
desired characteristics of session routes" it should be specified in the
COS.